Method and system for data security, validation, verification and provenance within independent computer systems and digital networks

ABSTRACT

A system and method for reliably and securely recording and storing all attributes of data, such as for the identification and authorization of individual identity as well as attributes relating to it and personal data including but not limited to individual&#39;s physical description, bank details, travel history, etc. (the “Personally Identifiable Information “PII”). PII can be difficult to manage in networks where correlation between data sources is required. Thus, in some embodiments, the system combines a distributed database to create a framework for a robust security. The system manages the distributed database to associate transactions, or actions, using data, digital signatures, and/or cryptographic keys, which can be unique to an individual.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/212,348, filed on Dec. 6, 2018, which claims priority to U.S.Provisional Application Ser. No. 62/595,416, filed Dec. 6, 2017, and isrelated to U.S. patent application Ser. No. 15/480,313, filed Apr. 5,2017, which claims priority to U.S. Provisional Application Ser. No.62/318,648, filed on Apr. 5, 2016, and is also related to U.S. patentapplication Ser. No. 16/031,433, filed Jul. 10, 2018, which claimspriority to U.S. Provisional Application Ser. No. 62/530,755, filed onJul. 10, 2017, and which applications are hereby incorporated byreference in their entirety and for all purposes.

FIELD

The present disclosure relates to data security, and more specifically,but not exclusively, to a system and method for data security,validation, verification, and provenance within independent computersystems and digital networks.

BACKGROUND

Traditional and generally accepted security measures and common securityinfrastructure—such as passwords, key management software, andtwo-factor authentication approaches—have failed to deliver reliable andsecure protection of both the infrastructures they are meant to protect,as well as the individual user's personal data.

The increased number of hacks, attacks, security breaches, successfulfraud attempts, and stolen passwords from end-users—and even entiredatabases from private companies as well as public/governmentorganizations—have led to declining trust from users regardingorganizations that provision their credentials and integrity of thepersonal data that is used to provide user access. Generally, datacompromise generates a lack of confidence in trusting personalidentifiable information to anyone. This increased user fear and concernfor individual data privacy, as well as personal data safety held bythird parties, have led to increased technical challenges fororganizations to maintain and protect the personal identifiableinformation of their users. For example, conventional methods typicallyrequire increased resources to improve data center monitoring andsecurity—including firewalls, secure environments, data breachdetection, penetration testing, resilience exercises against potentialhacks and security breaches.

The main reason for the lack of security in conventional systems is thatoutdated concepts and poor fundamental design is commonly used intechnologies and practices aimed at establishing and protecting identityas well as existing (or a potential user's) personal details. Mostorganizations using these outdated technologies are forced to store anypersonal data collected centrally and store the personal data “asis”—unencrypted. Even when it's encrypted, such data currently can bestolen and used elsewhere for nefarious purposes, due to the singlepoint of compromise in the conventional approaches.

While there are many faults within conventional personal identitymanagement systems, some examples include: storing data in its initialor apparent form; storing data in open form or un-encrypted; storingdata in encrypted form that can easily be restored to their initial oropen form; storing of passwords including digital keys; existence ofbackdoors; not decentralized, “all eggs in one basket” storage; having asingle point of compromise; and conceptually offering any form of“trusted authorities.”

In view of the foregoing, a need exists for an improved system for datamanagement in an effort to overcome the aforementioned obstacles anddeficiencies of conventional data collection, storage, query, andmanagement systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary top-level block diagram illustrating oneembodiment of a data management system including a client device forpartitioning data and generating cryptographic data.

FIG. 2 is an exemplary top-level block diagram illustrating oneembodiment of a data flow for generating a Data Secret ID using the datamanagement system of FIG. 1.

FIG. 3 is an exemplary top-level block diagram illustrating anembodiment of a data flow for generating a Data Public ID using the datamanagement system of FIG. 1.

FIG. 4 is an exemplary top-level block diagram illustrating anembodiment of a data flow for generating a Proof of Inclusion using thedata management system of FIG. 1.

FIG. 5 is an exemplary top-level block diagram illustrating anembodiment of a data flow for validating a Proof of Inclusion using thedata management system of FIG. 1.

FIG. 6 is an exemplary top-level block diagram illustrating anembodiment of a data flow for data storage using the data managementsystem of FIG. 1.

FIG. 7 is an exemplary top-level block diagram illustrating anembodiment of a Verifiable Data Structure that can be used by the datamanagement system of FIG. 1 for altering and verifying cryptographicdata.

FIG. 8 is an exemplary top-level block diagram illustrating anembodiment of an audit dataset that can be used by the data managementsystem of FIG. 1.

FIG. 9 is an exemplary top-level block diagram illustrating anembodiment of a data flow process for auditing that can be executedusing the data management system of FIG. 1.

FIG. 10 is an exemplary top-level block diagram illustrating anembodiment of a data flow path for data retrieval and validation usingthe data management system of FIG. 1.

It should be noted that the figures are not drawn to scale and thatelements of similar structures or functions are generally represented bylike reference numerals for illustrative purposes throughout thefigures. It also should be noted that the figures are only intended tofacilitate the description of the preferred embodiments. The figures donot illustrate every aspect of the described embodiments and do notlimit the scope of the present disclosure.

DETAILED DESCRIPTION

Since currently-available personal identity management systems aredeficient because of outdated data storage and data managementtechniques, a system for data management including recording, storing,verifying, authenticating and authorizing of cryptographic data and itsattributes can prove desirable and provide a basis for a wide range ofdata management applications, such as for digital identity access tointernational travel, telecommunication services, financial services,banking, credit, insurance, medical records, and to prevent fraud ormisuse of identity information. This result can be achieved, accordingto one embodiment disclosed herein, by a data management system 300 asillustrated in FIG. 1.

Turning to FIG. 1, the data management system 300 is shown as includinga client 301. In a preferred embodiment, the client 301 receives data302 in its original, unencrypted form. In other embodiments, the data302 includes data that has been subjected to cryptographic functionssuch as cryptographic primitives including, but not limited to hashfunctions, digital signature schemes and encryption functions. The data302 can be of any nature, form, and complexity. The data 302 is shown ascomprising data sub-parts 303A-M. It should be understood that there canbe any number of data sub-parts 303 comprising the data 302. By way ofanother example, the data 302 can include a single sub-part 303 (notshown), thereby representing the full data set of the data 302, or up tosub-part 303M, thereby including M sub-portions 303 of the data 302. Inyet another embodiment, a selected sub-part 303 can overlap with thedata represented and/or contained by another sub-part 303. In otherwords, the same portion of data can be maintained in two or moreseparate sub-parts 303. Similarly, the sub-parts 303 can also includeonly data that is unique from each other. In an even further embodiment,a selected sub-part 303 can include other data that is not directlyreceived as the data 302 (e.g., metadata for a selected sub-part 303).

The client 301 provides the data sub-parts 303 to a cryptographicfunction 304 (e.g., such as a cryptographic function 304A shown in FIG.1). The cryptographic function 304 can include a cryptographic primitivesuch as, but not limited to, a hash function, a digital signaturescheme, a blinding/unblinding technique, and/or an encryption functionin order to generate one or more cryptographic sub-parts 305. In someembodiments, the cryptographic function 304 can include any combinationof cryptographic primitives to generate the cryptographic sub-parts 305.In a preferred embodiment, the cryptographic function 304 comprises ahash function (e.g., SHA-1, SHA-2, SHA-3 or script). In an even furtherembodiment, the number of resulting cryptographic sub-parts 305 can bedifferent from the number of data sub-parts 303. In yet anotherembodiment (not shown), the data 302 can be provided to thecryptographic function 304A without the need for the data sub-parts 303.

The client 301 then provides the cryptographic sub-parts 305 to a secondcryptographic function 304B to generate cryptographic data 307. In someembodiments, the second cryptographic function 304B can include anycombination of cryptographic primitives to generate the cryptographicdata 307. In a preferred embodiment, the second cryptographic function304B comprises a hash function (e.g., SHA-1, SHA-2, SHA-3 or script). Insome embodiments, the second cryptographic function 304B can be the sameas the cryptographic function 304A. In yet another embodiment, the data302 can be directly provided to the second cryptographic function 304Bto generate the cryptographic data 307. In some embodiments, a treestructure (e.g., a Merkle Tree or other similar structure) can bederived from the set of cryptographic sub-parts 305 before applying thesecond cryptographic function 304B to the tree root.

In a preferred embodiment, the client 301 provides the cryptographicdata 307 and a blind factor 308 to a third cryptographic function 304Cto generate blinded data 310, as shown on FIG. 2. The blind factor 308can represent a random value. In some embodiments, a public key (notshown) of a storage 311 can be used as an additional input to the thirdcryptographic function 304C. In some other embodiments, the blind factor308 is optional. In some other embodiments, the blinded data 310 can bethe same as the cryptographic data 307. In some embodiments, the thirdcryptographic function 304C can include any combination of one or morecryptographic primitives to generate the blinded data 310. In someembodiments, the third cryptographic function 304C can be the same asthe cryptographic function 304A and/or the second cryptographic function304B. In a preferred embodiment, the third cryptographic function 304Cincludes a Verifiable Random Function, such as, but not limited to,RSA-FDH-VRF for blinding.

The blinded data 310 is then sent to the storage 311 as shown on FIG. 2.In some embodiments, the storage 311 can reside on, or includecomponents of, the client 301. The data management system 300 issuitable for use with any type of storage 311, such as a decentralizeddistributed storage, including, but not limited to, for example, adistributed hash table, a distributed database, a peer-to-peerhypermedia distributed storage (e.g., InterPlanetary File System(IPFS)), a distributed ledger (e.g., Blockchain), an operating memory, acentralized database, a cloud-based storage, and/or the like. In otherembodiments, the storage 311 is not decentralized or comprises acombination of distributed, decentralized servers, and centralizedservers. In even further embodiments, the storage 311 can be maintainedin operating memory of any component in the system 300.

FIG. 2 shows the storage 311 providing the blinded data 310 and aprivate key 312 to a fourth cryptographic function 304D for producing ablinded signature 314. In a preferred embodiment, the private key 312 isa (large) private cryptographic secret key. In some embodiments, thefourth cryptographic function 304D can include any combination of one ormore cryptographic primitives to generate the blinded signature 314. Insome embodiments, the fourth cryptographic function 304D includes adeterministic encryption/signature scheme. In even further embodiments,the blinded signature 314 can be the same as the blinded data 310. In apreferred embodiment, the fourth cryptographic function 304D comprises aVerifiable Random Function, such as, but not limited to, RSA-FDH-VRF,for generating the blinded signature 314. In yet another embodiment, thefourth cryptographic function 304D can be the same as the thirdcryptographic function 304C.

The blinded signature 314 can be returned to the client 301 as shown onFIG. 2. The client 301 can provide the blinded signature 314 and theblind factor 308 to a fifth cryptographic function 304E to generate aData Secret ID 316. In some embodiments, a public key (not shown) of thestorage 311 can be also used as an additional input for the fifthcryptographic function 304E. In some embodiments, the fifthcryptographic function 304E includes any combination of one or morecryptographic primitives to generate the Data Secret ID 316. In yetanother embodiment, the Data Secret ID 316 can be the same as theblinded signature 314. In a preferred embodiment, the fifthcryptographic function 304E includes a Verifiable Random Function (e.g.,RSA-FDH-VRF) for unblinding the blinded signature 314. In someembodiments, unblinding includes shifting/unshifting a digital signatureby a blinding factor to recover the original signature from the shiftedsignature. Thereby, the Data Secret ID 316 is mathematically binded withthe cryptographic data 307. In further embodiments, the fifthcryptographic function 304E can be the same as the fourth cryptographicfunction 304D and/or the third cryptographic function 304C.

In some embodiments, the Data Secret ID 316 can be the same as thecryptographic data 307—this is helpful in the case when the data 302 hasa high combinatorial entropy preventing the possibility of brute-forcingthe original data 302 comprised by the cryptographic data 307. In someother embodiments, the storage 311 may not be involved in the process ofgenerating the Data Secret ID 316. However, in a preferred embodiment,due to the fact that the client 301 blinds the cryptographic data 307before sending it to the storage 311, the storage 311 is never being ina possession of the original data 302 and the cryptographic data 307.Accordingly, the client 301 advantageously protects the original data302 and the cryptographic data 307 to prevent brute-force or reverseengineer attacks on the blinded data 310 alone. Advantageously, in thepreferred embodiment, it is not possible for the storage 311 to tamperwith the Data Secret ID 316—by the methods disclosed herein of the datamanagement system 300, the Data Secret ID 316 can be subjected to theverification and validation processes on a client 301 side which wouldflag any data tampering. The data management system 300 advantageouslyprevents brute-force attacks of the Data Secret ID 316 from the originaldata 302 on the client 301 by forcing the client 301 to send blindeddata 310 to the storage 311 where it is then subject to the fourthcryptographic function 304D with the private key 312 known only to thestorage 311. Without knowledge of the private key 312, it iscomputationally inefficient to brute-force the Data Secret ID 316 on theclient 301.

Turning to FIG. 3, the client 301 provides the data sub-parts 303 andthe Data Secret ID 316 to a sixth cryptographic function 304F in orderto generate a set of salts 318. In some embodiments, the number of salts318 can be different from the number of data sub-parts 303. In someembodiments, the sixth cryptographic function 304F includes one or morecryptographic primitives to generate the salts 318. In a preferredembodiment, the sixth cryptographic function 304F includes a hashfunction, such as but not limited to SHA-1, SHA-2, SHA-3, or script. Inother embodiments, the sixth cryptographic function 304F can be the sameas the cryptographic functions 304E, 304D, 304C, 304B, and/or 304A.

The client 301 combines correlated data sub-parts 303A-M and salts318A-M together and provides the resulting dataset 323 to a seventhcryptographic function 304G to generate a set of salted cryptographicsub-parts 320A-M. In some embodiments, the seventh cryptographicfunction 304G includes any combination of one or more cryptographicprimitives to generate the set of salted cryptographic sub-parts 320. Inyet another embodiment, the Data Public ID 322 can be the same as theData Secret ID 316. In a preferred embodiment, the seventh cryptographicfunction 304G includes a hash function, such as but not limited toSHA-1, SHA-2, SHA-3, or script for hashing each part of the resultingdataset 323.

The client 301 provides the salted cryptographic sub-parts 320 to aneighth cryptographic function 304H to generate a Data Public ID 322 asshown on FIG. 3. In some embodiments, the eighth cryptographic function304H includes any combination of one or more cryptographic primitives togenerate the Data Public ID 322. In some embodiments, Data Public ID 322can be the same as the cryptographic data 307 and/or the Data Secret ID316. In a preferred embodiment, the eighth cryptographic function 304Hincludes a hash function, such as but not limited to SHA-1, SHA-2,SHA-3, or script. In some embodiments, the eighth cryptographic function304H can be the same as the seventh cryptographic function 304G.

Advantageously, the data management system 300 prevents a brute-forceattack of the all possible combinations that can be used as the DataPublic ID 322 for all possible data 302 and/or the cryptographic data307 that resides on the client 301. Accordingly, it is difficult foranyone to receive or steal any meaningful data in its original easilyaccessible form, even for the data 302 that has a low combinatorialentropy. In some embodiments, the Data Public ID 322 can be usedpublicly (e.g., published) without the fear of a brute-force orreverse-engineered attack.

For each given data sub-part 303, the client 301 can generate a proof ofinclusion 324, such as shown in FIG. 4. Although FIG. 4 illustrates asingle proof of inclusion 324A generated for the selected sub-part 303A,it should be understood that the same process can be applied for any ofthe data sub-parts 303B-M to generate corresponding proofs of inclusion324B-M. The proof of inclusion 324A for the sub-part 303A includes thesalt 318A and the cryptographic sub-parts 320B-M.

Advantageously, the proof of inclusion 324 for the selected sub-part 303can be used to mathematically prove that the selected sub-part 303 isindeed a part of the Data Public ID 322 as shown in FIG. 5. Turning toFIG. 5, the data sub-part 303A is combined with the salt 318A. Theresulting combination is combined with the remaining part of the proofof inclusion 324 and form a dataset 325. The client 301 then providesthe dataset 325 to a ninth cryptographic function 3041 to generate thecryptographic data 326. Only if the cryptographic data 326 equals to theData Public ID 322, then the proof of inclusion 324 is valid, correct,and proves that the data sub-part 303A is the part of the original data302 having the Data Public ID 322. In some embodiments, the top-levelorganization shown in FIG. 5 can be implemented on the storage 311.

FIG. 6 illustrates a top-level flow diagram of transmission of a dataset332 to the storage 311 using the Data Public ID 322 as an identifier. Ina preferred embodiment, the client 301 receives the data 327 in itsoriginal, unencrypted form. In other embodiments, the data 327 includesdata that has been subjected to cryptographic functions such ascryptographic primitives disclosed herein. The data 327 can be of anynature, form, and complexity. In some embodiments, the data 327 can bethe same as the original data 302. In some embodiments, the data 327 canbe the same as one or many of the data sub-parts 303.

The client 301 provides the data 327 and a private key 333 to a tenthcryptographic function 304J (e.g., a cryptographic primitive) togenerate cryptographic data 331. In a preferred embodiment, the privatekey 333 is a (large) private cryptographic secret key known only to theclient 301. In some embodiments, the private key 333 need not be used.In a preferred embodiment, the tenth cryptographic function 304Jincludes a FIPS-186-3 (or its analogues) to produce a digital signature(e.g., the cryptographic data 331) for the data 327. In otherembodiments, different digital signatures schemes and approaches areused.

The client 301 also provides the data 327 and the Data Secret ID 316 toan eleventh cryptographic function 304K to generate cryptographic data329. In some embodiments, the eleventh cryptographic function 304Kincludes one or more cryptographic primitives to generate thecryptographic data 329. In a preferred embodiment, the eleventhcryptographic function 304K includes an encryption scheme, such as, butnot limited to, Advanced Encryption Standard (AES), Pretty Good Privacy(PGP), Rivest-Shamir-Adleman (RSA), Data Encryption Standard (DES),Blowfish cipher, Twofish cipher, and other similar encryptions schemes.

As shown in FIG. 6, the client 301 forms the dataset 332 with the DataPublic ID 322 as an identifier, the cryptographic data 329, and thecryptographic data 331. In some embodiments, more data can be presentedwithin the dataset 332 (e.g., meta-data can be included). The dataset332 can be sent to the storage 311. In some embodiments, proofs ofinclusion 324 of at least one sub-part 303 can be sent by the client 301with the dataset 332 to the storage 311.

Turning to FIG. 7, the storage 311 is shown as including a VerifiableData Structure 334. In a preferred embodiment, a Sparse Merkle Tree isused as the Verifiable Data Structure 334. Using the Data Public ID 322,the storage 311 can uniquely identify a current checksum 335A storedwithin the Verifiable Data Structure 334 against the corresponding DataPublic ID 322. The storage 311 then provides the cryptographic data 329to a twelfth cryptographic function 304L (e.g., a cryptographicprimitive) to produce cryptographic data 344. In some embodiments, thestorage 311 verifies the cryptographic data 331 by checking thecryptographic data 331 against a public key (not shown) of the client301 paired with the private key 333.

The client 301 then provides the current checksum 335A and thecryptographic data 344 to a thirteenth cryptographic function 304M toproduce a new checksum 335B. In some embodiments, the thirteenthcryptographic function 304M includes one or more cryptographicprimitives to generate the new checksum 335B. In a preferred embodiment,the thirteenth cryptographic function 304M includes hashing, such as,but not limited to, SHA-1, SHA-2, SHA-3, or script.

As shown in FIG. 7, a new tree root 336B is computed. In a preferredembodiment, the client 301 sequentially computes the new tree root 336B.In some embodiments, the data management system 300 also encodes dataabout each change onto a distributed ledger, such as a ledger 339 shownin FIG. 7. The data management system 300 is suitable for use with awide range of ledgers 339, such as any immutable distributed ledger,including, for example, a public Blockchain (e.g., Bitcoin® Blockchain,Ethereum® Blockchain, etc.) and/or a private Blockchain and/or the like.In some embodiments, the storage 311 can be the same as the ledger 339.In some embodiments, the ledger 339 comprises a combination of publicand/or private Blockchains. In some embodiments, the data managementsystem 300 provides the safety and integrity for multiple amounts ofrecords and events within the system 300, all within the parameters of asingle ledger transaction on the ledger 339. In some other embodiments,each transaction corresponds to a single event within the storage 311.In alternative embodiments, each transaction represents a set of eventsor records within the storage 311. Each new record (or combination ofrecords) of a transaction within the storage 311 generates a ledgertransaction (not shown) into the ledger 339 as shown on FIG. 7, whichallows anyone to verify and validate the existence and accuracy of thisdata entry.

For example, when the ledger 339 represents a Bitcoin® Blockchain, theledger transaction represents a Bitcoin® Blockchain transaction and thenew tree root 336B is written into an ‘OP_RETURN’ field of the ledgertransaction. The ledger transaction can be broadcasted over a ledger 339network. As soon as a new block (reflecting the transaction) is createdon the ledger 339, the record(s) which the data managemnt system 300 hasplaced within the ledger transaction is secured inside the ledger 339itself. Stated in another way, once the ledger transaction is in theblock, it is difficult to revert or tamper it, so it is difficult tochange its history. In other embodiments, the ledger 339 executes smartcontracts (e.g., Ethereum® Blockchain, Hyperledger® Fabric orHyperledger® Indy). The smart contract is a computer protocol intendedto digitally facilitate, verify, or enforce the negotiation orperformance of a contract. The smart contracts allow the performance ofcredible transactions without third parties. These transactions aretrackable and irreversible. These ledger transaction comprising the newtree root 336B (raw or hashed) within the body (contents) of the ledgertransaction is distributed over the ledger 339 network, replayed onevery Blockchain node and represents a global state change of the ledger339. In yet another one embodiment, only some of the sequential new treeroots 336 are being published to the ledger 339.

In some embodiments, a combination of the cryptographic data 329 and thecryptographic data 331 can be saved within the storage 311 with theassociated Data Public ID 322. This information is readable for theclient 301 only if the client 301 is in possession of the original data302 due to the fact that the Data Secret ID 316 is used as a decryptionkey for the cryptographic data 329. The storage 311 cannot reconstructeither the Data Secret ID 316 or original data 302, thereby providingfull privacy for the client 301. In a preferred embodiment, the datamanagement system 300 is suitable to store more than one value/recordassociated with the Data Public ID 322 cryptographic data 329 and/orcryptographic data 331.

Advantageously, the client 301 can perform the audit of any operation,performed by the storage 311. Any data tampering or unsanctioned dataremoval can be detected, such as shown on FIG. 8. Turning to FIG. 8, theclient 301 receives an Audit Dataset 341 for the operation of interestfrom the storage 311. The Audit Dataset 341 includes at least an OldProof Path 340A, a New Proof Path 340B, a corresponding Data Public ID322, and the cryptographic data 344.

With reference now to FIG. 9, in order to validate, check and verify theoperation being under audit, the client 301 provides the checksum 335and Cryptographic data 344 received from the storage 311 to thethirteenth cryptographic function 304M to produce an Audit checksum 345.The client 301 changes the checksum 335 within the Old Proof Path 340Ato the Audit checksum 345 and rebuilds the whole Verifiable DataStructure 334 up to the new Audit Root 346. An operation (ortransaction) being audited is validated, checked and verified if theAudit checksum 345 equals the new checksum 335B, the Audit Root 346equals the New Root 336B, and the Audit Root 346 and the New Root 336Brespectively equals the Published Root 342.

Advantageously, the client 301 need not be in possession of the originaldata 302 to be able to validate each operation from the storage 311.

In a preferred embodiment, the client 301 performs the audit of eachoperation happening on the storage 311—each New Root 336B becomestrusted once audit is successfully completed.

In order to get all of the data associated with the Data Public ID 322from the storage 311, the client 301 sends Data Public ID 322 (known tohim) to the storage 311 as shown on FIG. 10. The storage 311 locates allof the cryptographic data 329A-X and/or 322A-X associated with the DataPublic ID 322 and sends them back to the client 301. Advantageously, theclient 301 cannot read the original data 327 from the cryptographic data329 without the knowledge of the Data Secret ID 316—the Data Secret ID316 is used as a key to decrypt the cryptographic data 329. Andconversely, the client 301 that is in possession of the Data Secret ID316 can read the original data 327. Authenticity of the each ofcryptographic data 329A-X can be checked by the client 301 throughvalidating correlated cryptographic data 331A-X.

As an advantage, the client 301 can check that all of the cryptographicdata sets 329 for the corresponding Data Public ID 322 were returnedcorrectly and in full and that the storage 311 is not tampering withdata or hiding some data. In order to do that, a client 301 providesreceived cryptographic data 329A-X to the twelfth cryptographic function304L separately from each other in order to generate a set of thecorresponding cryptographic data 344A-X. As shown on FIG. 10, the client301 provides resulted cryptographic dataset 344A-X to the thirteenthcryptographic function 304M one by one, sequentially, providing theresult back to the function input until all of the cryptographic data344A-X were processed through the thirteenth cryptographic function304M. Resulted data equals the Current checksum 348 if and only if thestorage 311 has provided the client 301 with all of the storedcryptographic data 329 for the Data Public ID 322.

In some embodiments, the data management system can determine a proof ofabsence similar to a proof of inclusion described herein. For example,in a preferred embodiment, if no cryptographic data 329A-X (and/or 331)were ever stored within the storage 311 for a given Data Public ID 322,the storage 311 provides a mathematical proof of absence to client 301.Accordingly, the storage 311 generates a special Proof Path (not shown)comprising special a known empty value as the Current checksum 348. Theempty value is known for every user of the data management system 300.The client 301 then validates the Proof Path described above—onlyauthentic proofs of absence would pass this validation.

Advantageously, the methods and systems described herein provides asecure and private storage solution allowing the client 301 to store andget access to the original data 302 of any nature, form, and complexity.The Data Secret ID 316 can be generated only if the client 301 isalready in a possession of the original data 302. Moreover, the DataSecret ID 316 and, accordingly, the Data Public ID 322 cannot be derivedfrom the original data 302 on the client 301 without the storage 311involvement in the process—it is a prevention of possible brute-forceattack, especially for the original data 302 having a low entropydistribution (passport data, for instance).

At the same time, the privacy of the client 301 is preserved—the storage311 receives only the blinded data 310, which, by itself, is not enoughto restore the original data 302. Advantageously, the storage 311 cannottamper with data identifiers 322 and 316 generation because the blindedsignature 314 can be effectively checked, asserted, and validated on theclient 301. The Data Public ID 322 advantageously can be shared, becomepublic, and used as the public identifier for the original data302—there is no efficient way to restore neither the original data 302nor the Data Secret ID 316 out of the Data Public ID 322 alone.

The original data 302 partitioning and proofs of inclusion 324generation process provides an efficient way to store, retrieve,manipulate and validate data sets 302 and 327 of any size and complexitydue to the fact that a client 302 don't have to generate thecryptographic data sets 331 for each of the data 302 sub-parts 303.Moreover, data partitioning provides an advantage of partial datamatching and provable search within the storage 311. This, in fact,provides an advantage of proving that the storage 311 indeed stores asub-part 303 of the data 302 related to the Data Public ID 322 withoutthe need to reveal any other information rather than the sub-part 303 ofthe data 302 that the client 301 is already in possession of and arelated proof of inclusion 325, which by itself does not provide anyuseful additional information for an attacker.

The datasets 327 stored within the storage 311 can be accessed, read,and decrypted by the client 301 only if the client 301 is already in apossession of the original data 302 due to the fact that data 327 isencrypted using the Data Secret ID 316 that could be generated from theoriginal form of data 302 only. The storage 311 has no efficient way toread stored datasets 327—data privacy of the client 302 is preserved aswell.

The system 300 provides an advantage of the provable audit processdescribed above, allowing the client 301 to ensure that the storage 311does not tampering with the data 302 and/or the datasets 327 it storesand there is no altering or removal of the datasets 327 due to theprocess of using Verifiable Data Structures 334 and publishing its roots336A, 336B to the append-only Ledger 339.

The disclosed embodiments are susceptible to various modifications andalternative forms, and specific examples thereof have been shown by wayof example in the drawings and are herein described in detail. It shouldbe understood, however, that the disclosed embodiments are not to belimited to the particular forms or methods disclosed, but to thecontrary, the disclosed embodiments are to cover all modifications,equivalents, and alternatives.

What is claimed is:
 1. A method for managing secured data withinindependent computer systems and digital networks, the methodcomprising: generating a cryptographic data stream by processingoriginal data representing the secured data on a local client devicethrough a cryptographic function; generating blinded data by providingthe cryptographic data stream and a blind factor to a secondcryptographic function; generating a blinded signature by providing thegenerated blinded data and a private key to a third cryptographicfunction of a storage device, the private key accessible only to thestorage device; and generating a data secret identifier by providing thegenerated blinded signature and the blind factor to a fourthcryptographic function, wherein the generated data secret identifier ismathematically binded with the generated cryptographic data stream, andthe storage device is never in possession of the original data and thegenerated cryptographic data stream.
 2. The method of claim 1, furthercomprising: partitioning the original data on the local client deviceinto one or more original data sub-parts prior to said generating thecryptographic data stream; generating one or more cryptographic datasub-parts by processing the partitioned original data sub-parts on thelocal client device through a first cryptographic function, wherein saidgenerating the cryptographic data stream comprises processing thegenerated cryptographic data-sub parts through the cryptographicfunction.
 3. The method of claim 2, further comprising deriving a treestructure from the generated cryptographic data-sub parts prior to saidgenerating the cryptographic data stream.
 4. The method of claim 2,further comprising generating a data public identifier, comprising:generating a set of salts by processing the partitioned original datasub-parts and the generated data secret identifier through a fifthcryptographic function; combining the set of salts and the partitionedoriginal data sub-parts by associating a selected salt with itscorresponding data sub-part; generating a set of cryptographic salts byprocessing the combined set of salts and the partitioned original datasub-parts data through a sixth cryptographic function; and generatingthe data public identifier by processing the set of cryptographic saltsthrough a seventh cryptographic function.
 5. The method of claim 4,further comprising generating a proof of inclusion for each partitionedoriginal data sub-part, a selected proof of inclusion for a selectedpartitioned original data sub-part includes its corresponding salt andthe generated set of cryptographic salts, the selected proof ofinclusion for mathematically establishing that the selected partitionedoriginal data sub-part is included in the generated data publicidentifier.
 6. The method of claim 5, further comprising mathematicallyestablishing that the selected original data sub-part is included in thegenerated data public identifier by forming a dataset by combining theselected original data sub-art and the selected proof of inclusion;generating a proof cryptographic data by processing the dataset throughan eighth cryptographic function; determining whether the proofcryptographic data equals the data public identifier.
 7. The method ofclaim 4, further comprising providing the generated cryptographic datastream and the data public identifier to a verifiable data structure,the verifiable data structure comparing a current checksum with the datapublic identifier.
 8. The method of claim 7, further comprisingproducing a new checksum by processing the current checksum and thegenerated cryptographic data stream to a twelfth cryptographic datastream.
 9. The method of claim 1, wherein said generating blinded datacomprises providing a random value as the blind factor.
 10. The methodof claim 1, wherein said generating blinded data further comprisesproviding a public key of the storage device to the second cryptographicfunction.
 11. The method of claim 1, wherein said generating thecryptographic data stream comprises processing the original data througha hash function.
 12. The method of claim 1, further comprising creatingan associated ledger transaction in a distributed ledger comprising saidgenerated blinded signature of the storage device.
 13. A method formanaging secured data within independent computer systems and digitalnetworks, the method comprising: generating a cryptographic data streamby processing original data representing the secured data on a localclient device through a cryptographic function; generating blinded databy providing the cryptographic data stream to a second cryptographicfunction; generating a blinded signature by providing the generatedblinded data and a private key to a third cryptographic function of astorage device being different than the local client device, the privatekey accessible only to the storage device; and generating a data secretidentifier by providing the generated blinded signature to a fourthcryptographic function, wherein the generated data secret identifier ismathematically binded with the generated cryptographic data stream. 14.The method of claim 13, further comprising generating a data publicidentifier, comprising: generating a set of salts by processing thepartitioned original data sub-parts and the generated data secretidentifier through a fifth cryptographic function; combining the set ofsalts and the partitioned original data sub-parts by associating aselected salt with its corresponding data sub-part; generating a set ofcryptographic salts by processing the combined set of salts and thepartitioned original data sub-parts data through a sixth cryptographicfunction; and generating the data public identifier by processing theset of cryptographic salts through a seventh cryptographic function. 15.A computer-implemented system for managing secured data withinindependent computer systems and digital networks, the methodcomprising: a client device for generating a cryptographic data streamby processing original data representing the secured data through acryptographic function, generating blinded data by providing thecryptographic data stream and a blind factor to a second cryptographicfunction; a verifiable storage device in communication with the clientdevice for generating a blinded signature by processing the generatedblinded data and a private key to a third cryptographic function, theprivate key accessible only to the storage device ; and wherein theclient device further generated a data secret identifier by providingthe generated blinded signature and the blind factor to a fourthcryptographic function, wherein the generated data secret identifier ismathematically binded with the generated cryptographic data stream, andthe storage device is never in possession of the original data and thegenerated cryptographic data stream.
 16. The computer-implemented systemof claim 15, wherein said client device further partitions the originaldata into one or more original data sub-parts prior to said generatingthe cryptographic data stream, generates one or more cryptographic datasub-parts by processing the partitioned original data sub-parts througha first cryptographic function, wherein the client device generates thecryptographic data stream by processing the generated cryptographicdata-sub parts through the cryptographic function.
 17. Thecomputer-implemented system of claim 16, wherein said client devicefurther derives a tree structure from the generated cryptographicdata-sub parts prior to said generating the cryptographic data stream.18. The computer-implemented system of claim 16, wherein said clientdevice further generates a data public identifier by generating a set ofsalts by processing the partitioned original data sub-parts and thegenerated data secret identifier through a fifth cryptographic function;combining the set of salts and the partitioned original data sub-partsby associating a selected salt with its corresponding data sub-part;generating a set of cryptographic salts by processing the combined setof salts and the partitioned original data sub-parts data through asixth cryptographic function; and generating the data public identifierby processing the set of cryptographic salts through a seventhcryptographic function.
 19. The computer-implemented system of claim 15,further comprising a distributed ledger in communication with theverifiable storage device for managing ledger transactions based on anytransaction occurring in the verifiable storage device.
 20. Thecomputer-implemented system of claim 15, wherein said verifiable storagedevice comprises at least one of a distributed hash table, a distributeddatabase, a peer-to-peer hypermedia distributed storage, a distributedledger, an operating memory, a centralized database, and a cloud-basedstorage.